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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 



The present document specifies the stage 2 of the LoCation Services (LCS) feature in UTRAN, which provides the 
mechanisms to support mobile location services for operators, subscribers and third party service providers. 

The purpose of this stage2 specification is to define the UTRAN LCS architecture, functional entities and operations to 
support location methods. This description is confined to the aspects of LCS within the UTRAN and does not define nor 
describe the LCS entities or operations within the Core Network. 

Location Services may be considered as a network provided enabling technology consisting of standardised service 
capabilities, which enable the provision of location applications. The application(s) may be service provider specific. 
The description of the numerous and varied possible location applications which are enabled by this technology are 
outside the scope of the present document. However, clarifying examples of how the functionality being described may 
be used to provide specific location services may be included. 

This stage 2 specification covers the UTRAN LCS functional model and entities, the location methods, state 
descriptions, and message flows. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 
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[6] GSM 03.32: "Universal Geographical Area Description". 

[7] 3G TS 22.100: "UMTS phase 1 Release 99". 
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[10] 3G TS 22.115: "Charging and Billing". 

[II] 3G TS 22.121: "The Virtual Home Environment". 

[12] 3G TS 23.110: "UMTS Access Stratum; Services and Functions". 

[13] 3G TS 25.413: "UTRAN lu interface RANAP signalling". 



ETSI 



3G TS 25.305 version 3.2.0 Release 1 999 8 ETSI TS 1 25 305 V3.2.0 (2000-06) 

[14] 3G TS 25.423: "UTRAN lur interface RNSAP signalling". 

[15] 3G TS 25.433: "UTRAN lub interface NBAP signalling". 

[16] 3G TS 25.214: "Physical layer procedures (FDD)" 

2.2 Informative references 

[17] Third generation (3G) mobile communication system; Technical study report on the location 

services and technologies, ARIB ST9 December 1998. 

[18] The North American Interest Group of the GSM MoU ASSOCIATION: Location Based Services, 

Service Requirements Document of the Services Working Group. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3G TS 22.101 and some of the terms and 
definitions in annex A apply. 

3.2 Abbreviations 

For the purposes of the present document, the GSM-related abbreviations given in GSM 01.04 and the UMTS-related 
abbreviations given in UMTS TS 22.101 apply. 



4 IVIain concepts 

A general description of location services and the service requirements is given in the specification 3G TS 22.071 [4]. 

By measuring radio signals the capability to determine the geographic location of the user equipment (UE) shall be 
provided. The location information may be requested by and reported to a client (application) associated with the UE, or 
by a client within or attached to the Core Network. The location information may also be utilised internally by UTRAN, 
for example, for location assisted handover or to support other features such as home location billing. The location 
information shall be reported in standard formats, such as those for cell based or geographical co-ordinates, together 
with the time-of-day and the estimated errors (uncertainty) of the location of the UE. 

It shall be possible for the majority of the UE (active or idle) within a network to use the feature without compromising 
the radio transmission or signalling capabilities of the UTRAN. 

The uncertainty of the location measurement shall be network design (implementation) dependent at the choice of the 
network operator. The uncertainty may vary between networks as well as from one area within a network to another. 
The uncertainty may be hundreds of metres in some areas and only a few metres in others. In the event that the location 
measurement is also a UE assisted process, the uncertainty may also depend on the capabilities of the UE. In some 
jurisdictions, there is a regulatory requirement for location service accuracy that is part of an emergency service. Further 
details of the accuracy requirements can be found in [4]. 

The uncertainty of the location information is dependent on the method used, the location of the UE within the coverage 
area and the idle or active state of the UE. Several design options of the UTRAN system (e.g. size of cell, adaptive 
antenna technique, path loss estimation, timing accuracy, base station surveys) shall allow the network operator to 
choose a suitable and cost effective location service feature for their market. 

There are many different possible uses for the location information. The location feature may be used internally by the 
UTRAN network (or attached networks), by value-added network services, by the UE itself or through the network, and 
by "third party" services. The feature may also be used by an emergency service (which may be mandated or "value- 
added"), but the location service is not exclusively for emergencies. 
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The UTRAN is a new radio system design without a pre-existing deployment of UE operating according to the air 
interface. This freedom from legacy equipment enables the location service feature design to make use of appropriate 
techniques to provide the most accurate results. The technique must also be a cost-effective total solution, must allow 
evolution to meet evolving service requirements and be able to take advantage of advances in technology over the 
lifetime of UTRAN deployments. 

4.1 Assumptions 

As a basis for the operation of LCS in UTRAN the following assumptions apply: 

in case an MS supports LCS, it shall support at least one of the locating method(s) specified in the present 
document; 

the provision of the location service in UTRAN is optional through support of the specified method(s) in Node-B 
and the associated RNC; 

LCS is applicable to any target UE whether or not the UE supports LCS, but with restrictions on choice of 
location method or notification of a location request to the UE user when LCS or individual location methods, 
respectively, are not supported by the UE; 

RNC contains SMLC functionality and LCS information is transported between RNCs via the lur interface; 

LCS shall be applicable for both circuit switched and packet switched services; 

the location information may be used for internal system operations to improve system performance; 

there are different types of LMU, e.g. a standalone LMU and/or LMU integrated in Node B; 

the location process shall include the option to accommodate several techniques of measurement and processing 
to ensure evolution to follow changing service requirements and to take advantage of advancing technology. 

4.2 Location Services Categories 

Generally there are four categories of usage of the location service: 

- the Commercial LCS (or Value Added Services); 

- the Internal LCS; 

- the Emergency LCS; 

- the Lawful Intercept LCS. 

These location services categories are further defined in [1] and [4]. 



4.3 Locating IVIethods 



The LCS feature utilises one or more location methods in order to determine the location of User Equipment (UE) or 
Mobile Stations. Locating the UE involves two main steps: 

signal measurements; and 

location estimate computation based on the measurements. 

The signal measurements may be made by the UE, the Node B or a dedicated location measuring unit (LMU). The basic 
signals measured are typically the UTRA radio transmissions, but some optional methods may make use of other 
transmissions such as general radio navigation signals. The location estimate computation may be made in the UE or by 
a calculation function located in the UTRAN. 
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4.4 Standard LCS Methods 

The present document, for Release '99, specifies the following LCS location methods: 

cell ID based method; 

OTDOA method with network configurable idle periods (the idle period configurability is to be specified in the 
specification); and 

network assisted GPS methods. 

NOTE: GPS based solutions are being standardised in TlPl; it is intended that the UTRAN navigational assisted 
solution will be synergistic with the work in TlPl. 

4.4.1 Cell ID Based Method 

In the cell ID based (i.e. cell coverage) method the location of an UE is estimated with the knowledge of its serving 
node-B. The information about the serving node-B and cell may be obtained by paging, locating area update, cell 
update, URA update, or routing area update. 

The cell coverage based location information can be indicated as the Cell Identity of the used cell, the Service area 
identity or as the geographical co-ordinates of a location related to the serving cell. The location information shall 
include a QoS estimate (e.g. regarding achieved accuracy). 

When geographical co-ordinates are used as the location information, the estimated location of the UE can be a fixed 
geographical location within the serving cell (e.g. location of the serving node-B), the geographical centre of the serving 
cell coverage area, or some other fixed location within the cell coverage area. The geographical location can also be 
obtained by combining information on the cell specific fixed geographical location with some other available 
information, such as the signal Round Trip Time (RTT). 

The operation of the cell ID based location method is described in clause 8. 

4.4.2 OTDOA-IPDL Method with network configurable idle periods 

This method involves measurements made by the UE and LMU of the UTRA frame timing (e.g. SFN-SFN observed 
time difference). These measures are then sent to a Position Calculation Function (PCF) in the Serving RNC where the 
location of the UE is calculated. 

Optionally, a PCF may be included in the UE, in which case the calculation of the location from the measurements may 
alternatively be performed in the UE. 

The detailed description of the OTDOA-IPDL location method and its operation are described in clause 9. 

4.4.3 Network Assisted GPS Methods 

These methods make use of UEs which are equipped with radio receivers capable of receiving signals from the Global 
Positioning System (GPS). 

The operation of the network assisted GPS methods is described in clause 10. 

4.5 Other methods 
4.5.1 Angle of Arrival (AOA) 

The location method may make use of the angle of arrival of the radio signals to estimate the UE location. This 
technique may, for example, make use of the sector of the base station used for receiving or transmitting to establish the 
location region and to assist to resolve ambiguity in other techniques. Some other techniques may make use of narrow 
beam antennas to resolve the direction between the UE and the base station to a very small angle. 

The AOA techniques and the signalling required for their support, are FFS. 
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4.5.2 Observed Time of Arrival (OTOA) 

The location service technique may make use of measurements of the time of arrival of signals. A UE, for example, 
which has available a suitable reference time, may measure the time of arrival of signals from the base stations and 
others sources. Some of these may include reference signals from satellites. The time-of-arrival may be used to estimate 
the distance from the source and hence derive a location estimate. 

The OTOA technique may also be used to measure signals transmitted by the UE. Base stations which are able to 
receive signals from the UE, and which share a suitable reference time, may each measure the time of arrival of signals 
from the UE. These times-of-arrival may be used to estimate the distance to the UE and hence derive a location 

estimate. 

The OTOA techniques and the signalling required for their support, are FFS. 

4.5.3 Reference Node-Based Positioning (OTDOA-RNBP) 

The RNBP method is based on the OTDOA. The main principle of the RNBP method is that it chooses a reference node 
for providing auxiliary measurements for its location calculation. The reference node may be a mobile equipped by a 
GPS receiver that provides its co-ordinates, a fixed or movable LCS service provider equipment, a mobile capable of 
using cellular relay technique (e.g. located at the soft handover area). 

RNPB can also utilised with other methods. It is especially useful in case of NLOS from/to the required number of 
neighbouring base stations. This may occur when the UE is located at the area where it may suffer from the hearability 
effect. Additionally it can support the LCS even in case UTRAN is not equipped by IPDL like mechanism to combat 
the hearability effect. 

4.5.4 OTDOA - Positioning Elements (OTDOA-PE) 

The PE method is based on OTDOA and makes use of Positioning Elements (PE) located within the coverage area. PEs 
are placed in accurately known locations other than those of the Node B equipment. They synchronise to the downlink 
in a cell and transmit their symbols at predefined - or signalled - offsets with regard to the arrival of the beginning of the 
BCH frame at the PE location. The offsets may be chosen to have a fixed relation to the occurrence of the idle periods 
in each cell. Each PE transmits a different and identifying code which is selected from the group of codes to which the 
16 SSC codes belong to. The use of other signals (e.g. CIPCH) instead of SSC codes is for further study. 

The time difference which is observed and reported by the UE is the difference - with respect to the time of arrival at 
the UE - between the first path of the BCH from the serving cell and the first path of the 256 chip code transmitted by a 
PE. The measurements result in an estimate of the UE distance to the PEs. 

PE deployment is optional and may be used in conjunction with other methods in order to increase location accuracy in 
certain areas or to achieve a minimum desired accuracy in locations where reception of satellites and/or base stations 
other than the serving one is problematic (indoors, edge of cellular coverage, etc.). It may also be used as a stand alone 
method. 



UTRAN LCS Architecture 



Figure 5.1 shows the general arrangement of the Location Service feature. This illustrates, generally, the relation of 
LCS Clients and servers in the core network with the UTRAN. The definition and operation of LCS entities operating in 
the core network is outside the scope of the present document. The LCS entities within the UTRAN communicate with 
the Core Network (CN) across the lu interface. Communication among the UTRAN LCS entities makes use of the 
messaging and signalling capabilities of the UTRAN. 

As part of their service or operation, the LCS Clients may request the location information of User Equipment (UE) 
(UE without a valid SIM/USIM) or mobile stations. There may be more than one LCS client. These may be associated 
with the core network, associated with the UTRAN, operated as part of a UE application or accessed by the UE through 
its access to an application (e.g. through the Internet). 

Within the UTRAN, typically the serving RNC, receives authenticated requests for LCS information from the core 
network across the lu interface. LCS entities then manage the UTRAN resources, including the Node-Bs (base stations), 
LMU, the UE and calculation functions, to estimate the location of the UE and return the result to the CN. 
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Figure 5.1 : General arrangement of LCS in UIVITS 



5.1 LCS Operations 



The schematic functional description of LCS operations in UMTS is defined in [1]. 

Upon request from the UMTS LCS entities or for internal operations, the UTRAN LCS functional entities will: 

- request measurements, typically from the UE and one or more Node-B radio apparatus; 
send the measurement results to the appropriate calculating function within UTRAN; 

- receive the result from the calculating function within UTRAN; 

- perform any needed co-ordinate transformations; 

send the results to the LCS entities in the core network or to application entities within UTRAN. 

In the event that the client is internal to UTRAN the request may be made directly to the UTRAN LCS entities as the 
internal clients are considered to be "pre-authorised". 

As part of its operation, the UTRAN LCS calculating function may require additional information. This may be 
obtained by the function directly by communication with a database, or it may be through a request to UTRAN LCS 
entities that will mediate the request and return of information from the appropriate database (or databases if more than 
one is needed to fulfil the requests). 

There may possibly also be available independent information that is able to supply the location information directly, or 
may be able to supply auxiliary information to the calculation function. The UTRAN LCS co-ordination function, as 
part of its activity to supervise the location process, may query the UE or other elements of the UTRAN to determine 
their capabilities and use this information to select the mode of operation. 

This general operation is outlined in the following (generic) sequence diagram figure 5.2. This figure is not intended to 
show the complete LCS operation for UTRAN, but to simply to outline the basis for operation. 
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Figure 5.2: General sequence for LCS operation 



5.2 High-Level Functions 



Several functional groupings may be defined to describe the LCS. These groupings occur in both the Core Network and 
the UTRAN. The overall LCS functional grouping is described in reference [1]. Each grouping encompasses a number 
of functional components and functions. 

The functions within the UTRAN are described in more detail in the following subclauses of the present document. 

Within UTRAN the functional entities may be grouped as follows: 

the Internal Client group; 

the UTRAN System Handling group; 

the Positioning group. 

5.2.1 Co-ordination, Measurement and Calculation Functions 

These UTRAN functions (including functions in the System handling and Positioning groups) provide the 
co-ordination, measurement and calculation functions needed to provide a location estimate. The functions interface 
with the requesting application and select the appropriate location method and speed of response. The functions 
co-ordinate the operations of the radio and measurement equipment to transmit the needed signals and to make the 
needed measurements. The measurements may be made by Node-Bs, radio apparatus associated with the Node-B or 
separate Location Measurement Units (LMU) that may be associated with Node-B, independently located or remote 
(i.e. communicating over the Uu interface). 

The functions may also access databases or other sources of information appropriate for the location method. The 
functions also provide the calculation functions appropriate for the location method to estimate the UE location and the 
accuracy of the report. The functions may also make co-ordinate translations to the geographic co-ordinate system 
requested by the application. The functions also may record information on the usage of the LCS that may be used for 
administrative purposes (e.g. forwarded to a billing function in the Core Network). If needed by the location method, 
the functions will ensure the broadcast of information and gather and update information concerning UTRAN operating 
parameters (e.g. timing of Node-B transmissions) needed for LCS operations. 

These entities are mainly concerned with the location method, controlling the radio equipment and performing the 
calculations to determine the location and thus may be associated with the RNC in the UTRA access network. These 
functions may receive location requests from either the core network or from applications internal to the UTRAN. 

The UTRAN LCS entities may also request the subscription and authorisation functions in the core network to 
authenticate an application or a UE subscription or to verify the subscriber privacy parameters. 
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These functions communicate with the core network across the lu interface, with other entities in the UTRAN across the 
lur interface and with the Node-B and LMU across the lub interface and with the UE and the remote LMU across the 
Uu interface. 

5.3 UTRAN LCS Functional Entities 

The diagram of the UTRAN LCS functional entities is shown in figure 5.3. In this arrangement, the LCS cHents in the 
core network communicate with the UTRAN LCS entities across the lu interface. The LCS RNC Handling Entities and 
the Positioning Handing Entities work together with the UE to measure and calculate the location information for the 
requested target UE. These entities within the UTRAN are described in more detail in the following subclauses. 

The figure shows the general arrangement of the Location Service feature in UTRAN. LCS entities are added to the 
UTRAN to provide the location service. Communication among these entities makes use of the messaging and 
signalling capabilities of the UTRAN across the lu, lur, lub and Uu interfaces. A Location Measurement Unit (LMU) is 
also added to the UTRAN to make measurements as needed by the selected location method. 

This figure does not include elements of the next generation mobile Core Network, but focuses on those that participate 
with the LCS functions in the UTRAN. The association of the LCS entities within the Core Network (CN) (e.g. with 
3G-MSC or 3G-SGSN) is outside the scope of the present document and is not illustrated in the diagram. 

Within the UTRAN, the LCS Entities may be associated with, or part of the RNC, the Node-B and the UE. Internal LCS 
Applications may also be part of the RNC and the UE. 

The mobile position calculation function (PCF) is logically associated with the Serving RNC in UTRAN. 

The LCS in UMTS also makes use of the standardised lur interface between RNCs, when base station information, 
measurements and results are collected. 

The functional model presented in the figure includes functional entities for UE utilising either or both circuit switched 
(CS) and packet switched (PS) services. This model also supports of all the entities needed for different location 
methods (e.g. network based, mobile based, mobile assisted, and network assisted (see note 1) methods) exploiting 
either uplink or downlink measurements. 

NOTE 1 : In this approach mobile station may use the GPS technique but still make use of auxiliary information 
from the serving network. 

Implementations may often associate the UTRAN LCS Entities with an RNC (as illustrated in the figure). However, for 
networks with a small volume of LCS requests, the LCS Entities in the UTRAN may also be implemented as a separate 
element (server) which interfaces with the RNCs, and the Node-B/LMUs. 

NOTE 2: the Interface to be used for this separated LCS Entity is for further study. 
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Figure 5.3: UTRAN LCS Functional Entities 



5.3.1 Internal Client Group 



5.3.1.1 



Internal UTRAN Location Client Function (U-LCF) 



The Location Client Function (U-LCF) represents a logical interface between the internal UTRAN LCS applications 
and the LCS RNC Handhng entities (e.g. the Location System Control Function (U-LSCF) in the RNC). 

NOTE: There is not necessarily a requirement for a LCCF (Location Client Control Function) for the UTRAN 
Internal Client as is described for external clients in reference [1] (the system stage specification). 

The UTRAN may make use of location information for internal operations such as location assisted handover. In such a 
case, a U-LCF representing the internal UTRAN LCS application may communicate with the U-LSCF to request and 
receive the location information. 



5.3.2 UTRAN System Handling group 



5.3.2.1 



UTRAN Location System Control Function (U-LSCF) 



The UTRAN Location System Control Function in RNC is responsible for co-ordinating location requests within the 
RNC handling entity. This function manages call-related and non-call-related location requests and allocates network 
resources for handling them. This function "insulates" the Location clients in the Core Network from the detailed 
operation of the location method in order that the UTRAN may be used by several types of core network and with 
several location methods. 

The U-LSCF provides flow control between simultaneous location requests. Simultaneous location requests must be 
queued in a controlled manner to account for priority requests (e.g. for Emergency Clients). The details of the flow 
control, priority selection and queuing are beyond the scope of the present document. 

The U-LSCF will select the appropriate location method based on the availability of resources and parameters of the 
location request. The U-LSCF co-ordinates resources and activities needed to obtain data (e.g. base station geographic 
co-ordinates) needed for the location method. It also records LCS RNC usage data for the location service request that 
may be passed to a Location System Recording Function (U-LSRF) or OA&M function in the Core Network. 

If the location technique requires the broadcast of system information, the LSCF initiates and maintains this activity 
through the Position Radio Co-ordination Function (U-PRCF). Broadcast information (such as the geographic co- 
ordinates of the base stations) may be required, for example, to support a Position Calculation Function (U-PCF) 
located in the mobile unit (UE). These broadcasts may also include other information (such as currently observable 
satellites) that may assist a UE in the use of external location services. 
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The information to be broadcast is selected based on the location techniques offered for use by the LCS and the needs of 
the UE. This broadcast information may be specially coded (i.e. encrypted) to ensure its availability only to subscribers 
of the service. The use of broadcasts or other methods for signalling to the UE or the LMU may be selected based on 
the chosen location method. 

The information to be broadcast could include, for example: 

identification and spreading codes of the neighbouring base stations (the channels that are used for 
measurements); 

Relative Time Difference (RTD), i.e. the timing offsets, asynchronity between base stations, could be based on 
measurement results obtained by LMUs; 

- roundtrip delay estimates in connected mode; 

the geographic location, co-ordinates, of the neighbouring base stations; 

the idle period places within the frame structure for multiple base stations; 

the local time-of-day. 

Some of this information may be broadcast to support other UTRAN operations (e.g. handover). The function of the 
LSCF is to ensure information is broadcast when needed for the LCS operations and the LSCF may make use of other 
UTRAN processes to do so. 

If there are frequency differences between the (unsynchronised) base stations, the OTDOA measurements must be 
reported together with the time-of-day they were made (timestamp). This is necessary so that the appropriate value of 
the RTD may be used by the calculation function. 

5.3.2.2 UTRAN Location System Operations Function (U-LSOF) 

The Location System Operations Function (LSOF) is responsible for provisioning of data, location capabilities, data 
related to clients and subscription (LCS client data and UE data), fault management and performance management of 
LCS within the RNC. 

An LSOF may be associated with each entity. The LSOF interacts with Internal (OAM) Clients for administration and 
maintenance of the data. 

5.3.3 Positioning group 

5.3.3.1 UTRAN Position Radio Co-ordination Function (U-PRCF) 

The UTRAN Position Radio Control Function manages a location request for a UE through overall co-ordination and 
scheduling of resources to perform location measurements. This function interfaces with the U-PSMF, the U-PRRM 
and the U-PCF. The U-PRCF determines the location method to be used based on the location request, the QoS, the 
capabilities of the UTRAN, and the UE's capabilities. The U-PRCF also manages the needed radio resources through 
the U-PRRM. It determines which U-PSMFs are to be involved, what to measure, and obtains processed signal 
measurements from the U-PSMF. 

Some location methods may involve measurements made at the UE. In this case the U-PRCF interfaces with the UE to 
obtain the measurements (or the location results if they have been determined by the UE). Some location methods may 
involve measurements or information from several sources, including radio units at several Node-B (or other Location 
Measurement Units (LMU)) and involve a series of transmissions and receptions. The U-PRCF entity also provide 
ancillary measurements in case of network-assisted location method. Ancillary information may be extracted from 
navigating systems like GPS. 

The U-PRCF forwards the signal measurement data to the U-PCF. 

It is the function of the U-PRCF to co-ordinate the sequence of activities and compensate for failures (if they occur) to 
provide the location estimate. 
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5.3.3.2 UTRAN Position Calculation Function (U-PCF) 

The UTRAN Position Calculation Function is responsible for calculating the location of the UE (mobile unit). This 
function applies an algorithmic computation on the collected signal measurements to compute the final location 
estimate and accuracy. 

The U-PCF may also support conversion of the location estimate between different geographic reference systems. It 
may obtain related data (e.g.: base station geographic co-ordinates) needed for the calculation. There may be more than 
one calculating function available within, or associated with, the calculation function of the UTRAN. 

In the cell ID based location method, the U-PCF shall determine the geographical co-ordinates corresponding to the 
cell(s) associated with the the target UE. 

The Position Calculation Function is also responsible for estimating the accuracy of the location estimate. This accuracy 
estimate should include, for example, the effect of geometric dilution of precision (GDOP), the capabilities of the signal 
measuring hardware, the effects of multipath propagation and the effects of timing and synchronisation unknowns. The 
accuracy should be returned as a measure of distance in the same units as the location estimate. The accuracy zone may 
be reported as the axis and orientation of an ellipse surrounding the location estimate. 

5.3.3.3 UTRAN Position Signal Measurement Function (U-PSMF) 

The UTRAN Position Signal Measurement Function (U-PSMF) is responsible for performing and gathering uplink or 
downlink radio signal measurements for use in the calculation of a UE's location. These measurements can be location 
related or ancillary. 

There may be one or more PSMF within a UTRAN and they may be located at the UE, the Node-B, or a separate 
Location Measurement Unit (LMU). The PSMF, generally, may provide measurement of signals (i.e. satellite signals) 
in addition to measurements of the UTRA radio transmissions. The measurements to be made will depend on the 
selected location method. 

5.3.3.4 UTRAN Position Radio Resource Management (U-PRRM) 

The UTRAN Position Radio Resource Management entity is responsible for managing the effect of LCS operations on 
the overall performance of the radio network. This may ensure, for example, that the operation of the U-PSMF does not 
degrade the QoS of other calls. The U-PRRM handles following functions: 

controlling the variation of the UL and DL signal power level due to the LCS application; 

calculating the DL and UL power/interference due to UE location operations; 

to admit/reject the new LCS requests; 

co-operating with Admission Control, and entities of the RRM (such as power control) to provide the system 
stability in terms of radio resources; 

controlling the RTD measurement mechanism. It may also forward the results of the RTD; ATD (or any similar 
timing parameter) measurements to the PRCF (or PCF); 

controlling the IPDL mechanism for location measurements. This may include the overall control of the 
periodical measurement fulfilment. Co-ordination among RNC (e.g. to assure non-overlapping idle periods) will 
be communicated through the lur interface. 

5.4 Assignment of LCS Functional Entities to UTRAN Elements 

The preceding figure 5.3 and the following table 5.1 show the generic configuration for different location methods, 
including network-based, mobile-based, mobile-assisted and network-assisted methods. With this approach both the 
network and the mobiles are able to measure the timing of signals and compute the mobile's location estimate. 
Depending on the applied location method it is possible to utilise the corresponding configuration containing all needed 
entities. For instance, if a network-based location method is applied, the entities that are involved in measuring the 
mobile's signal and calculating its location estimate are allocated to the network elements of the access stratum. On the 
other hand, in case mobile-based or network-assisted methods are used these entities should be allocated to the mobile 
station. 
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Table 5.1 : Example Allocation of LCS Functional Entities to Network Elements 
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5.5 Functional Description of UTRAN LCS Network elements 
5.5.1 Radio Network Controller (RNC) 
5.5.1.1 Serving RNC 

NOTE: Adapted from 03.7 1 , to be elaborated for UTRAN. 

The Serving RNC (SRNC) is a network element of UTRAN and contains functionality required to support LCS in one 
PLMN. 

The SRNC manages the overall co-ordination and scheduling of resources required for the location of a mobile. It also 
calculates the final location estimate and estimates the achieved accuracy. 

The SRNC may control a number of LMUs for the purpose of obtaining radio interface measurements to locate or help 
locate MS subscribers in the area that it serves. The SRNC is administered with the capabilities and types of 
measurement produced by each of its LMUs. Signalling between an SRNC and LMU is transferred using the lub 
interface, sometimes the lur interface [and also the Uu interface for possible stand-alone LMUs]. The following 
measurements returned by an LMU to an SRNC have a generic status in being usable for more than one location 
method: 

- radio interface timing information. 

The SRNC and GMLC are connected through the 3G-VMSC or 3G-SGSN. When the VMSC and GMLC are in 
different PLMNs, they are interconnected via the Lg interface. 



5.5.1.2 



Other RNC 



5.5.2 Node-B 

5.5.3 Location measurement unit (LMU) 

The LCS Measurement Unit (LMU) entity makes measurements (e.g. of radio signals) and communicates these 
measurements to the S-RNC (e.g. the PRCF). The LMU contains a PSMF and may also perform calculations associated 
with the measurements. 

The LMU may make its measurements in response to requests (e.g. from the S-RNC (e.g. the PRCF)), or it may 
autonomously measure and report regularly (e.g. timing of Node-B transmissions) or when there are significant changes 
in radio conditions (e.g. changes in the RTD). 

There may be one or more LMU associated with the UTRAN and an LCS request may involve measurements by one or 
more LMU. The LMU may be of several types and the S-RNC will select the appropriate LMUs depending on the LCS 
method being used. 
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The LMU may be used, for example, to measure UTRA transmissions either uplink or downlink. These measurements 
may be made either, for example, to locate the UE or to measure a system parameter needed by the LCS system such as 
the timing offset (RTD) of transmissions of two or more base stations. The LMU may also measure other transmissions, 
such as those of satellite navigation systems (i.e. the Global Position System (GPS)) and either report the measurements 
for use by the S-RNC (e.g. the PCF), or report the location results as determined by internal calculations of the LMU). 
The details of the measurements to be made by the LMU will be defined by the chosen LCS method. 

An LMU makes radio measurements to support one or more location methods. These measurements fall into one of two 
categories: 

(a) location measurements specific to one UE and used to compute its location; 

(b) assistance measurements applicable to all UEs in a certain geographic area. 

All location and assistance measurements obtained by an LMU are supplied to a particular S-RNC associated with the 
LMU. Instructions concerning the timing, the nature and any periodicity of these measurements are either provided by 
the S-RNC or are pre-administered in the S-RNC (e.g. using O&M). 

There are two classes of LMU: 

- Stand-Alone LMU: accessed over the UTRAN air interface; 

- Associated LMU: accessed over the lub interface. 

The associated LMU signalling protocol is the NBAP. The protocol for stand-alone LMU signalling has not been 
defined yet. 

NOTE 1 : The stand-alone LMU signalling protocol could be, for example, RRC or LLP, but this is still for further 

study. 

Stand-Alone LMU 

A stand-alone LMU is accessed exclusively over the UTRAN air interface (Uu interface). There is no other connection 
from the stand-alone LMU to any other UTRAN network element. 

NOTE 2: This does not preclude a stand-alone LMU from also communicating with other networks (e.g. GSM) 
through interfaces that are not part of the present document. 

A stand-alone LMU has a serving-Node-B that provides signalling access to a controlling S-RNC. A stand-alone LMU 
also has a serving 3G-MSC, VLR and a subscription profile in an HLR. A stand-alone LMU always has a unique IMSI 
and supports all radio resource and mobility management functions of the UTRAN air interface that are necessary to 
support signalling. A stand-alone LMU shall support those connection management functions necessary to support LCS 
signalling transactions with the S-RNC and may support certain call control functions of to support signalling to an 
S-RNC using a circuit switched data connection. 

NOTE 3: A network operator may assign specific ranges of IMSI for its LMUs and may assign certain digits within 
the IMSI to indicate the associated S-RNC. Certain digits in the IMSI may also be used as a local 
identifier for an LMU within an S-RNC. 

To ensure that a Stand-alone LMU and its associated S-RNC can always access one another, an LMU may be homed 
(camped) on a particular cell site or group of cell sites belonging to one 3G-MSC. For any Stand-alone LMU with a 
subscription profile in an HLR, a special profile may be used to indicate the assigned supplementary services (e.g. the 
SMS-PP MT for data download via the SIM application toolkit, and barring of all incoming and possibly outgoing 
calls). An identifier in the HLR profile also distinguishes an LMU from a normal UE. All other data specific to an LMU 
is administered in the LMU and in its associated S-RNC. 

Associated LMU 

An associated LMU is accessed over the lub interface from an RNC. An associated LMU may make use of the radio 
apparatus and antennas of its associated Node-B. The LMU may be either a logically separate network element 
addressed using some pseudo-cell ID, or connected to or integrated in a Node-B. Signalling to an associated LMU is by 
means of messages routed through the controlling Node-B. 

An associated LMU may be separated from the Node-B, but still communicate with the S-RNC via the Node-B lub 
interface. The interface between the associated LMU and its Node-B is not part of the present document. 
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NOTE 4: An associated LMU is not precluded from also communicating with other networks (e.g. GSM) through 
interfaces that are not part of the present document. 

Measurements 

The assistance measurements obtained by an LMU have are generic and are usable by more than one location method. 
These include: 

- Radio Interface Timing measurements: include Absolute Time Differences (ATDs) or Relative Time 
Differences (RTDs) of the signals transmitted by Node-B, where timing differences are measured relative to 
either some Absolute Time Difference (ATD) or the signals of another Node-B (RTD); 

- Inter-System Timing measurements: include the Absolute Time Difference (ATD) or Relative Time 
Difference between the UTRAN radio signals transmitted by a Node-B and an external system such as the GPS 
satellite navigation system or GSM. 

5.5.4 UE 

The UE interacts with the measurement co-ordination functions to transmit the needed signals for uplink based LCS 
measurements and to make measurements of downlink signals. The measurements to be made will be determined by the 
chosen location method. 

The UE may also contain LCS applications, or access an LCS application through communication with a network 
accessed by the UE or an application residing in the UE. This application may include the needed measurement and 
calculation functions to determine the UE's location with or without assistance of the UTRAN LCS entities. 

The UE may also, for example, contain an independent location function (e.g., GPS) and thus be able to report its 
location, independent of the UTRAN transmissions. The UE with an independent location function may also make use 
of information broadcast by the UTRAN that assists the function. 



Signalling protocols and interfaces 



NOTE: This clause describes the information flows, the detailed messages and protocols are described in other 
clauses. 

6.1 LCS signalling between SRNC and MSC/SGSN 

LCS signalling between SRNC and MSC/SGSN is handled through the lu interface, which is described in clause 6.6.3. 

6.2 SRNC signalling to a target UE 

SRNC signalling to a target UE is described in clause 6.6.4. L 

6.3 Associated RNC signalling to a standalone LMU 

Associated RNC signalling to a standalone LMU is described in clause 6.6.4.2. 

6.4 Associated RNC signalling to a LMU in Node B 

Associated RNC signalling to a LMU in Node B is handled through the lub interface, which is described in clause 6.6.1. 

6.5 RNC-to-RNC signalling for LCS support 

The RNC-to-RNC signalling for LCS support is handled through the lur interface, which is described in clause 6.6.2. 
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6.6 Interfaces 

There are four interfaces through which the LCS entities communicate. These are the lu, the lur, lub and the Uu. 

NOTE: the interfaces between the Internal or External LCS applications and the 3G-MSC or 3G-SGSN are 
outside the scope of the present document. 

6.6.1 lu Interface 

The lu interface is used to communicate between the LCS functional entities in the Core Network and the LCS entities 
in the UTRAN. Further specification of the messages and operations for LCS across the lu interface may be found in 
reference [1]. 

6.6.2 lur Interface 

LCS operations at the lur interface are defined in [14]. 

The lur interface is used to communicate between the LCS functional entities associated with the serving RNC and 
other RNC in the UTRAN. The lur interface is also used to communicate between the serving RNC and the Internal 
LCS Applications in the UTRAN. The LCS entities associated with the serving RNC are responsible for co-ordinating 
and responding to location requests received from the LCS entities in the core network or Internal Clients. 

When communicating between the serving RNC and the UTRAN Internal LCS Applications (ILA), the messages and 
protocols are the same as those used over the lur interface. 

The lur interface is also used to communicate between the LCS Entities in the serving RNC and those in other RNC. 
The location method, for example, may require measurements by several LMU or Node-B, some of which may be 
associated with other RNC. Commands and responses from these LCS Entities are communicated over the lur interface. 
In some cases, the LCS Entities in the serving RNC may make use of entities associated with other RNC. For example, 
a calculating function (PCF) may be used in another RNC if the serving RNC is too busy or does not contain the 
function or database information required by the chosen location method. 

The lur interface may also pass messages relating to changes or reporting of the data associated with the Location 
System Operations Function (LSOF) in the RNC. 

lur shall be used for LCS signalling whenever it is available, even in the case when the RNCs connected to different 
3G-MSCS or 3G-SGSN. 

Within UTRAN, lur supports inter-RNC soft handover. Inter-RNC handover should also include LCS, meaning that 
whenever an inter-RNC soft handover occurs, lur should be able to support the functionality of the LCS entities in 
RNCs, including PCF, PRRM, PSMF, and LSOF. 

In addition, in case of SRNC relocation lur should support the relocation mechanism in order for DRNC to be able to 
handle the responsibility of SRNC in LCS process. That is, to transfer the PCF, PRRM, PSMF, and LSOF functionaUty 
from SRNC to DRNC. lur shall be used also to collect RTD and other LCS information from base stations under 
different RNCs that are not involved in handover. 

6.6.3 lub Interface 

LCS operations at the lub interface are defined in [15]. 

The lub interface is used to communicate among the LCS entities associated with the serving RNC, the Node-B and the 
associated Location Measurement Units (LMU). 

This interface passes the request for measurements, the measurement results and requests for LCS related transmissions 
or other radio operations needed by the location method (e.g. broadcast of parameters needed for a UE based location 
method). 

The lub interface may also pass messages relating to changes or reporting of the data associated with the Location 
System Operations Function (LSOF) in the Node-B or the LMU. 
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6.6.3.1 



Signalling between RNC and associated LMU 



Signalling exchanges between an RNC and a LMU under the control of that RNC will be specified in the NB AP 
protocol for associated LMUs. 

The protocol layers employed to enable signalling between the RNC and an associated LMU are defined in 25.430. The 
LMU signalling information elements are included directly in the NBAP protocol, defined in 25.433. 

6.6.4 Uu Interface 

LCS operations at the Uu interface are generally defined in [1]. This specification defines in more detail the procedures 
needed for messaging for each individual location method. 

The Uu interface is used to communicate among the LCS entities associated with the RNC, the UEs and the stand-alone 
Location Measurement Units (LMU) (the Uu interface is also used to communicate between the LCS entities in the core 
network and the UE. Those communications are beyond the scope of this specification). 

This interface may pass measurement requests and results to and from the UE or the stand-alone LMU. 

The Uu interface may also pass location requests from internal or external LCS Applications at the UE. 

NOTE: These requests may require the services of the LCS entities associated with the core network to 
authenticate clients and subscriber subscriptions to aspects of the LCS. 

The Uu interface may also be used for broadcast of information that may be used by the UE or stand-alone LMU for 
their LCS operations. This may, for example, include timing and code information about nearby Node-B transmissions 
that may assist the UE or LMU in making their measurements. 

The Uu interface may also pass messages relating to changes or reporting of the data associated with the Location 
System Operations Function (LSOF) in the UE or the remote LMU. 

6.6.4.1 Signalling between S-RNC and Target UE 

LCS related signalling between an S-RNC and a target UE is supported by the RRC protocol. 

The location Request to UE signalling flow is generic for all UE based or assisted location methods (OTDOA and 
Network Assisted GPS). 



S-RNC 



UE 



1 . RRC Measurement Control 



4. RRC Measurement Report 
< 



Figure 6.1 : OTDOA /GPS Location IVIessage Flow 

1. The S-RNC determines possible assistance data and sends a MEASUREMENT CONTROL request to the UE. 

2. Provided that location request meets the privacy criteria, the UE performs the requested measurements. If the UE 
is able to calculate its own location, and this is requested, the UE computes a location estimate based on 
measurements. Any assistance data necessary to perform these operations will either be provided in the 
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MEASUREMENT CONTROL request or be available from broadcast sources. The resulting measurements or 
location estimate are returned to UTRAN in a MEASUREMENT REPORT response. If the UE cannot fulfil the 
request, a MEASUREMENT CONTROL FAILURE message is returned. 



6.6.4.1.1 



Assistance Data Delivery to UE 



The assistance data signalling flow illustrated here is generic for UE based location methods, including OTDOA and 
Network Assisted GPS. Note that if the assistance data is sent as part of a broadcast message, then no assistance data 
acknowledgement is required. 




Figure 6.2: OTDOA or GPS Assistance Data Delivery Flow 

I. The S-RNC determines assistance data and sends it in the RRC MEASUREMENT CONTROL message to the 
UE. 



6.6.4.1.2 



Error Handling 



6.6.4.1.3 



Broadcast of Assistance Data 



In the UE Based OTDOA or Network Assisted GPS methods, where the measurements and/or location calculation is 
done in the UE, assistance data may be broadcast to the UE. 

The assistance data to be broadcast for UE Based OTDOA contains the Relative Time Difference (RTD) values (e.g. in 
case of a non-synchronised network) and base station co-ordinates. In addition, the broadcast data may contain other 
information to simplify the OTDOA measurements. The length of the message depends on how many neighbours are 
included in the assistance data. Part of the broadcast message (e.g. the serving and neighbour base station geographic 
co-ordinates) may be ciphered. 

Part of the broadcast message (e.g. the GPS differential corrections, ephemeris and clock corrections, almanac and other 
data) may be ciphered. 

The broadcast channel that is used for the OTDOA and GPS assistance data makes use of the common UTRAN 
broadcast service. 

6.6.4.1 .4 Signalling Flow for Assistance Data Broadcast Using the Common UTRAN 

Broadcast Service 

The assistance data broadcast to UEs can be signalled via the RRC Measurement Control message as shown in 
subclause 6.6.4.2 or it can be broadcast by the UTRAN within the system information. 



S-RNC 



UE 



SYSTEM INFORMATION 



Figure 6.3: Broadcast of system information 
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6.6.4.1 .5 LCS Assistance Data Ciphering 

To allow control of access to the assistance data, parts of the broadcast assistance data may be ciphered. Ciphering is 
done with a specific ciphering key delivered by the core network for this purpose. The management of the key is 
described in the System Aspects Stage 2 ([1]). 

6.6.4.1 .6 LCS Assistance Data Ciphering Algorithm 

NOTE: The text below is inherited from GSM. The choice of the algorithm should be discussed in 3GPP/S A. It 
can also be chosen to put this text in the System Aspect Stage 2. 

The algorithm used for ciphering the LCS assistance data is the standard 56-bit Data Encryption Standard (DES) 
algorithm. 

The deciphering of broadcast assistance messages is done in the UEs. The deciphering will utilize the deciphering keys 
delivered during the location update request. 

The RNC ciphers the parts of the LCS Broadcast Data message to be protected using the 56-bit DES algorithm and a 
ciphering keys (56 bits) and Ciphering Serial Number (16 bits) for the broadcast location area. 

The ciphered part is variable in length with one bit resolution. By using the LCS Broadcast Data message header, the 
UEs can determine what part of message is ciphered. 

Inputs to the 56-bit DES algorithm are the following: 

56-bit key K (deciphering key); 

16-bit Ciphering Serial Number from broadcast message which is denoted here by IV (Initialization Vector); 

- plain-text bits (the ciphered part of broadcast message). 

The ciphering process is illustrated in the following diagram. Ciphering is done by producing a mask bit stream which 
is then "XORed" bit-by-bit to the plain-text data to obtain the cipher-text data. First, the Initialization Vector (IV) is 
concatenated with 0-bits in order to achieve a 64-bit block Ii. This block is then encrypted by the DES algorithm using 
the key K. Output is a 64-bit block I2. This constitutes the first 64 bits of the mask bit stream. If the message is longer 
than 64 bits, then more bits are needed. These are produced by encrypting I2 again by the DES algorithm using the key 
K. The output is a 64-bit block I3. This is the next 64 bits of the mask bit stream. This iteration is continued until enough 
bits are produced. The unnecessary bits from the last 64-bit block Ij are discarded. The figure below illustrates the first 
two mask bit generations and the two ciphered 64-bit blocks. 
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1st 64-bit block of the broadcast message to be ciphered 



1st 64-bit ciphered biocl< to the broadcast message 



2nd Masl< Bit Stream (64 bits) 



2nd 64-bit block of the broadcast message to be ciphered 



2nd 64-bit ciphered block to the broadcast message 




XOR 



Figure 6.4: Data Assistance Ciphering Algorithm 

Deciphering is done similarly. The same mask bit stream is produced and these are XORed, bit-by-bit, to the cipher-text 
data bits. The result will be the plain-text data. 

6.6.4.2 Signalling between RNC and stand-alone LMU 

The use of stand-alone LMUs is FFS. If it is decided to have stand-alone LMUs in the standard, the signalling will be 
performed with the new protocol LLP. If no need is seen for the stand-alone LMUs the LLP protocol will not be defined 
and it will be remove from 25.305. 

The following figures illustrate the protocol layers used to support signalling between an RNC and a Stand-Alone LMU 
over the Uu interface. 
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6.6.4.2.1 



Signalling using a signalling bearer 
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Figure 6.5: Signalling between an RNC and a Stand-Alone LMU using a signalling bearer 



6.6.4.2.2 



Signalling using a radio bearer 
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Figure 6.6: Signalling between an RNC and a Stand-Alone LMU using a radio bearer 



£75/ 



3G TS 25.305 version 3.2.0 Release 1999 



27 



ETSI TS 125 305 V3.2.0 (2000-06) 



7 General UMTS location procedures 

NOTE: To be adapted from GSM 03.71. 

7.1 State description for RNC (for LCS) 

7.2 State description for LMU (stand-alone) 

7.3 State description for Node-B (for LCS) 

7.4 General network location procedures 

The following diagram illustrates the operations for the OTDOA-LCS when the request for location information is 
initiated by an LCS application signalled from the Core Network. As these operations are internal to the RNC, this 
diagram is to illustrate information flow and implementations may use alternate arrangements. 

This illustration only includes the information flow related to LCS operations and does not indicate other operations that 
may be required, for example, to establish a signalling connection between the UE and the SRNC. Also not illustrated is 
the signalling used to initiate the location service request (from the Location Client Function) from the Core Network or 
a UE based appUcation. 
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Figure 7.1 : OTDOA Signalling Operations 

1 . The operation begins with an authenticated request for location information about a UE from an application in 
the core network being received at the LSCF. The LSCF acts as interface between the Core Network and the 
LCS entities in the UTRAN. 
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2. The LSCF considers the request and the capabihties of the UE and the network and forwards the request to the 
appropriate PRCF in the Serving RNC. 

3. The PRCF requests from the UE the measurement of the OTDOA for the signals in the active and 
neighbourhood sets. These measurements may be made while the UE is in the idle state or while it is connected. 

4. If it is considered advantageous to do so, the PRCF requests the UE TX-Rx timing difference information from 
the UE. 

5. The UE returns the OTDOA measures to the PRCF. The PRCF receives the OTDOA information and co- 
ordinates obtaining other information to support the calculation request (not illustrated). 

6. The UE returns the UE TX-Rx timing difference information to the PRCF, together with a time stamp of when 
the value was obtained. 

7. If there are insufficient OTDOA measures, or it is otherwise considered advantageous to do so, the PRCF 
requests the RTT measure for the UE from the PSMF in the serving Node-B. 

8. The PRCF requests the RTD measures for the associated transmitters from the LSOF (database). These may be 
stored locally if they are constant over time, otherwise they must be updated to represent the RTD timing at the 
time-of-day the OTDOA measurements were made. 

9. The PSMF in the Node-B returns the RTT measures to the PRCF if they were requested. 

10. The LSOF returns the RTD information to the PRCF. 

11. The PRCF passes the OTDOA, RTD and, if necessary, RTT information to the PCF and requests a location 
calculation. The calculation may include a co-ordinate transformation to the geographic system requested by the 
application. 

12. The PCF returns the location estimate to the PRCF. This estimate includes the location, the estimated accuracy 
of the results and the time of day of the estimate. 

13. The PRCF passes the location estimate to the LSCF. 

14. The LSCF passes the location estimate to the Core Network. 
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7.5 Signalling procedures from the UIVITS system point of view 

7.6 Common procedures to support location 

7.6.1 Information transfer between a SRNC and a target UE 

7.7 Common procedures to support access to a LIVIU 

7.8 Common control procedures for LIVIUs 

7.8.1 Reset procedure 

7.8.2 Status query procedure 

7.8.3 Status update procedure 

7.9 Common procedures supporting LCS interaction between 
RNCs 

7.9.1 LCS information transfer between RNCs 

7.10 Exception procedures 

7.10.1 Procedures in the SRNC 

7.10.2 Procedures in a LIVIU 

7.10.3 Procedures in the target UE 

7.1 1 Radio interface timing procedures 

7.11.1 LMU functions 

7.11.2 SRNC functions 

7. 1 1 .3 LMU-SRNC interactions 

8 Cell ID based location method 

In the Cell ID based method, the S-RNC determines the identification of the cell providing coverage for the target UE. 
This subsection outlines the procedures for this location method. Sub-section 8.1 provides procedures for the 
determination of the cell ID depending on the operational status of the target UE. Sub-section 8.2 discusses the relation 
between the LCS location service and the Support of Localised Service Area (SoLSA) feature. Sub-section 8.3 provides 
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a procedure for the mapping of the Cell ID to a corresponding Service Area Identifier (S AI) to be returned to the LCS 
application in the core network. The general flow to determine the cell ID is shown in figure 8.1. 
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Figure 8.1 : Cell ID Based Method 



8.1 



Cell ID determination 



In order for the S-RNC to determine the cell ID when an LCS request is received, additional operations may be needed 
depending on the operational status of the UE. 

Figure 8.1 illustrates the procedure for the cell ID based location method when the UE is in different RRC states. When 
the LCS request is received from the core network the S-RNC checks the state of the target UE. If the UE is in a state 
where the cell ID is available, the target cell ID is chosen as the basis for the UE location. In states where the cell ID is 
not available, the UE is paged, so that S-RNC can establish the cell with which the target UE is associated. In order to 
improve the accuracy of the LCS response the S-RNC may also request RTT measurements from the Node B or LMU 
associated with the cell ID. The S-RNC may also map the cell ID to a corresponding Service Area Identifier (SAJ) to 
match the service coverage information available in the core network. 

The cell ID based method shall determine the location of the UE regardless of the RRC state, including URA_PCH, 
Cell_PCH, Cell_DCH, Cell_FACH, cell reselection, inter-system modes, as well as an idle mode. 

8.1.1 UE Cell ID is not known 

For UE for which the cell ID is not known at the time the LCS request is received at the S-RNC, the UE may be paged 
to locate its current cell ID. If the UE is in an idle mode and there is a need for it to be paged, then the paging may be 
initiated either by the core network or by the S-RNC in the UTRAN access network. For example, the UE can be forced 
to perform a transition to a Cell_FACH state to define the cell ID of its current cell. 

If the UE is in an idle mode, Cell_PCH state or in any other state when there is a need to page for the UE to obtain the 
cell ID, the Core Network may initiate paging, authentication and ciphering, as specified in TS 23.17L 

Alternatively, the cell ID may be determined as the one that was used during the last active connection to the UE. This 
determination should be accompanied by the time-of-day of the last connection in the cell. 
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8.1.2 UECell ID is known 

8.1 .2.1 UE not in Soft handover 

The cell ID may be determined as the cell that is providing an active connection for the UE at the time of receiving the 
LCS request at the S-RNC. 

8.1 .2.2 UE in Soft handover 

In order for the S-RNC to provide the geographical co-ordinates of a target UE in soft handover, the S-RNC combines 
the information about all cells associated with the UE. 

In soft handover, the UE may have several signal branches connected to different cells, reporting different cell IDs. A 
reference cell ID may be determined by the S-RNC based on the coverage area of each cell. The reference cell ID may 
be selected based on one or more of the following principles: 

the cell ID may be selected based on the parameters defining the quality of the received signal branches. That is, 
the cell ID with the best quality signal branch is selected as the reference cell ID; 

the cell ID may be selected that was used during connection set-up between the UE and the serving Node B; 

the cell ID of the cell most recently associated with the UE may be selected;; 

the cell ID of the latest "new" cell that the UE has started to receive, but has not yet been handed over to may be 
selected; 

the cell ID may be selected as the cell to which UE has the shortest distance (to the Node-B site); 

the cell ID may be selected as the cell that provides an active connection for the UE at the time of receiving 
theLCS request at the S-RNC. 

The selection may also be based on measurements of Round Trip Time, power levels and received signal strengths in 
UE and related Node B or LMU. 

Other relevant mechanisms such as Idle Period Downlink, (IPDL) or Site Selection Diversity Transmit power control 
(SSDT) should also be taken into account when applying the cell ID selection procedure for UE in a soft handover 
mode. 

8.2 Localised Service Area 

The Support of Localised Service Area (SoLS A) feature is quite close to the location service in principle, but SoLS A is 
based, for example, on radio network cell coverage and cell configuration. SoLSA has been standardised in GSM and is 
being developed for UTRAN. Some SoLSA service features like Exclusive Access and LSA only Access may be less 
applicable in UTRAN due to the 1 frequency reuse. 

It should be noted that the Service Area concept described in this specification is different from the Localised Service 
Area concept defined for SoLSA. 

8.3 IVIapping the Cell ID to Geographic Co-ordinates or a 
Service Area 

A UTRAN cell ID should be mapped to geographical coordinates or a Service Area Identifier (SAI) before being sent 
from UTRAN to the core network. The Service Area Identifier may include one or several cells. The mapping may be 
accomplished either in the S-RNC, in a Network Management System (NMS, including Network Management Unit, 
NEMU) or by co-operation of various access network elements. 

The core network may request the geographical co-ordinates or the SAI, or both for the target UE. The SAI may be used 
for routing of corresponding Emergency calls, or for CAMEL services to correspond to the usage of Cell ID in the core 
network of GSM. However, the MSC shall not send the Service Area Identity to GMLC. 
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Although the mapping of the cell(s) associated with the target UE into geographical co-ordinates by the S-RNC is not 
standardised, the response to the core network location request with geographical co-ordinates shall be as defined in TS 

23.032. 

It should be noted that the Service Area concept is different from the Localised Service Area concept used for SoLSA 
services. 

In order to determine a cell coverage estimate and to map it to the geographical coordinates or Service Area parameter 
Identity, the S-RNC may use parameters such as the best reference signal. Round Trip Time (RTT), as well as antenna 
beam direction parameters. 

Alternatively, the service area coverage of a cell may be determined by using a reference signal power budget. Based on 
the reference signal power budget it is possible to obtain, for example, the base station transmitted power, isotropic path 
loss, coverage threshold at coverage area border for a given location probability, and a cell radius for an indoor and 
outdoor coverage. 

The S-RNC may use a reference signal link budget based cell radius estimate, in conjunction with the cell identifier, to 
make a coverage estimation for the cell(s) related to the target UE. 

Additionally, the S-RNC may compare the received power levels with the power budget, whereby more accurate 
information of the location of the UE may be provided. 

Also, the interaction between neighbouring cell coverage areas may be used to determine a more exact location of the 
UE. 



OTDOA location method 



The primary standard OTDOA measurement is the "SFN-SFN observed time difference" observed at the UE. These 
measurements, together with other information concerning the surveyed geographic location of the transmitters and the 
relative time difference (RTD) of the actual transmissions of the downlink signals may be used to calculate an estimate 
of the location of the UE. Each OTDOA measurement for a pair of downlink transmissions describes a line of constant 
difference (a hyperbola (see note 1)) along which the UE may be located. The UE's location is determined by the 
intersection of these lines for at least two pairs of base stations. The accuracy of the location estimates made with this 
technique depends on the precision of the timing measurements, the relative location of the base stations involved (see 
note 2), and is also subject to the effects of multipath radio propagation. This is illustrated in the figure 9.1. 

NOTE 1 : This is really a figure in three dimensions, a hyperboloid. For convenience here, this will be simplified to 
the hyperbola representing the intersection of this surface with the surface of the earth. For location 
service in three dimensions the hyperboloid must be considered. 

NOTE 2: The geometry of the base station locations may affect the accuracy of the location estimate. The best 

results are when the base stations equally surround the UE. If they do not, there is a reduction in accuracy, 
which is sometimes termed the Geometric Dilution of Position (GDP). 

The primary OTDOA measurements (made by the UE) are sent to the Position Calculation Function (PCF) in the 
serving RNC. These measures are sent via signalling over the Uu, lub (and lur) interfaces between the UE and the 
SRNC (PCF). The calculation function makes use of the measurements, the known locations of the transmitter sites and 
the relative time difference of the transmissions to estimate the UE's location. 
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Figure 9.1 : OTDOA Location Method 

The OTDOA method may be operated in two modes: UE assisted OTDOA and UE based OTDOA. The two modes 
differ in where the actual location calculation is carried out. In the UE assisted mode, the UE measures the difference in 
time of arrival of several cells and signals the measurement results to the network, where a network element (the 
Position Calculation Function (PCF)) carries out the location calculation. In the UE based mode, the UE makes the 
measurements and also carries out the location calculation, and thus requires additional information (such as the 
location of the measured base stations) that is required for the location calculation. The signalling requirements for the 
two OTDOA modes are described in a later subclause. As the LCS involves measurements, there is always uncertainty 
in the results. Physical conditions, errors and resolution limits in the apparatus all contribute to uncertainty. To 
minimise the uncertainty in the LCS result, it is important that as many measurements of RTT and TDOA (and others) 
as are possible for a UE are provided to the PCF. Thus it is important that the standard method for LCS not be restricted 
to rely on a single measure. The UE thus provides OTDOA measures for as many pilot signals as it can receive. The 
pilot signals to be measured shall include those in the "cell reselection and monitoring set" and those in the "cell 
selection set". 

In order to support the OTDOA method, the locations of the UTRAN transmitters needs to be accurately known by the 
calculation function (PCF). This information may be measured by appropriate conventional surveying techniques (see 
note 3). The surveyed location should be the electrical centre of the transmitting antenna (and not the location of the 
radio equipment building). The use of antenna diversity, beamforming or beam steering techniques may cause the 
effective antenna location to change with time and this information will need to be communicated to the PCF to assist 
with its calculations. The methods of measuring the location of the UTRAN transmitters are outside the scope of the 
present document. 



NOTE 3: These surveying methods may, for example, make use of a GPS receiver. 



In order to support the OTDOA method, the relative time difference (RTD) of the downlink transmissions must also be 
known by the calculation function (PCF). If the UTRAN transmitters are unsynchronised, the RTD will change over 
time as the individual clocks drift. Thus, measurements of RTD may need to be made regularly and the calculation 
function updated appropriately. The measurement of the RTD is outside the scope of the present document (see note 4). 

NOTE 4: One convenient method is to make use of an LMU at a fixed location. This unit measures the observed 
time differences of all the local transmitters and reports these to the PCF. These measures may then be 
converted (translated) into the actual (absolute) relative time difference for each of the transmitters by 
making use of the known location of the LMU and the transmitters. 

In some conditions a sufficient number of downlink pilot signals may not be available for measure at the UE. This may 
occur, for example, if the UE is located quite close to the UTRAN transmitter and its receiver is blocked by the strong 
local transmissions. This is referred to as the "hearability" problem. 
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9.1 Use of Idle Periods 

For realising location based services the support of physical layer is a prerequisite, so that the measurements required 
for the terminal location calculation can be carried out. In UTRAN there are several factors that must be taken into 
account while considering the physical layer procedures related to location services: 

hearability: a basic consequence of a CDMA radio system is that a terminal near its serving base station cannot 
hear other base stations on the same frequency. In order to calculate terminal location the terminal should be able 
to receive at least three base stations. To facilitate this some special means are required; 

asynchronous network causes significant uncertainty to the time-difference-of-arrival (TDOA) measurements. 
To compensate for the effects of this, the relative time difference (the synchronicity) between base station 
transmissions must be measured, and used for correcting TDOA measurement; 

capacity loss: signalling related to location calculation may take capacity from other services. This capacity loss 
should be minimised. 

Based on the results of the work done in ARIB SWG2/ST9 (see reference [17]) a solution for the above mentioned 
hearability problem is the IPDL (Idle Period DownLink) method. In this method each base station ceases its 
transmission for short periods of time (idle periods). During an idle period of a base station, terminals within the cell 
can measure other base stations and the hearability problem is reduced. Also, during idle periods the real time 
difference measurements can be carried out. Because the IPDL method is based on forward link (downlink) the location 
service can be provided efficiently to a large number of terminals simultaneously. 

The specification and operation of the IPDL technique are provided in the following subclause. 

9.1 .1 Operation and specification of idle periods 

The operation and specification of idle periods can be found in TS 25.214 (reference [16]). 

9.2 Relative Time Difference (RTD) 

In order to calculate the estimate of the location of the UE, the calculation function needs to know: 

the OTDOA measurements; 

the surveyed geographic locations of the base stations that have had their signals measured; and 

the actual relative time difference between the transmissions of the base stations at the time the OTDOA 
measurements were made. 

The accuracy of each of these measurements contributes to the overall accuracy of the location estimate. The 
measurement of the RTD is described in the following. 

There are several approaches to determining the RTD. One is to synchronise the transmissions of the base stations. In 
this technique the RTD are known constant values (see NOTE) that may be entered in the database and used by the 
calculation function when making a location estimate. The synchronisation must be done to a level of accuracy of the 
order of tens of nanoseconds (as 10 nanoseconds uncertainty contributes 3 metres error in the location estimate). Drift 
and jitter in the synchronisation timing must also be well controlled as these also contribute uncertainty in the location 
estimate. Synchronisation to this level of accuracy is currently only readily available through satellite based time- 
transfer techniques. Generally in the TDD operating mode, the base stations are synchronised. 

NOTE: The transmission times may all be aligned to a common reference (such as UTC) in which case all RTD 
have a common value. However, in a more general case the transmissions may have a fixed offset with 
reference to UTC, and thus the RTD values are non-zero and may be stored in the database for use by the 
calculation function. 

Alternatively (typically in FDD mode), the base stations may be left to free run within some constraint of maximum 
frequency error. In this scenario, the RTD will change (slowly) with time. The rate of change will depend on the 
frequency difference and jitter between base stations. If, for example, the maximum frequency difference between two 
base stations is +10'^, then the start of transmission of a 10 millisecond code sequence will drift through a cycle in about 
1 390 hours (or 57 days). With this relatively slow rate of drift the RTD can be measured by fixed units at known 
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locations (these are LMUs, Location Measurement Units) and stored in the database for use by the calculation function. 
The jitter and drift of the individual oscillators in each base station may cause the change of timing to slow, remain 
constant or reverse direction over time. Ongoing measurements of the RTD may be made to assure the most current 
values are available for the calculation function. The RTD measurement units may be co-located with the base stations 
or installed at other convenient locations in the UTRAN coverage area, and report their results through the UTRAN 
signalling channels. 



9.3 Time of Day (ToD) 



If there are frequency differences between the (unsynchronised) base stations, as noted in the previous subclause, the 
OTDOA measurements must be reported together with the time-of-day they were made (timestamp). This is necessary 
so that the appropriate value of the RTD may be used by the calculation function. 

In order to assure less than a 20 nanosecond uncertainty in the RTD value, the time of day must be known to better than 
10 seconds (if the maximum frequency difference between the base stations is +10"'). The method by which the ToD is 
measured is FFS [but the frame number (which provides a 10 millisecond resolution) or encryption counter used in the 
downlink transmissions may provide a convenient measure]. 



9.4 Base Station Synchronisation 



It is preferable that the location methods do not require the base station network to be synchronised. The needed level of 
synchronisation accuracy for LCS is not by any means straightforward to achieve. The necessary information of 
Relative Time Differences (RTD) between base stations can be measured by dedicated units (LMU, Location 
Measurement Unit) and distributed in the network (e.g. as broadcast information). Also, the measurements of RTD may 
benefit from the Idle Period DownLink (IPDL) option. 

In the TDD operating mode the base stations will typically be synchronised and this may be of assistance to the LCS 
technique. 

9.5 OTDOA-IPDL IVIodes 

There are two modes of operation for the OTDOA method. In the UE assisted mode, the UE measures the difference in 
time of arrival of several cells and signals the measurement results to the network, where a network element (the 
Position Calculation Function (PCF)) carries out the location calculation. In the UE based mode, the UE makes the 
measurements and also carries out the location calculation, and thus requires additional information (such as the 
location of the measured base stations) that is required for the location calculation. This information is provided by the 
Location System Information Function (LSIF). 

Table 9. 1 lists the required information for both OTDOA modes. The range of values for the listed parameters are FFS. 
The required information can be signalled to the UE either in a broadcast channel or partly also as dedicated signalling. 
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Table 9.1 : Information required for UE assisted and UE based OTDOA in the UTRAN (LSIF) to UE 
direction ('Yes' = information required, 'No' = Information not required) 



Information 


UE assisted 
OTDOA 


UE based 
OTDOA 


Intra frequency Cell Info (neighbour list). 


Yes 


Yes 


Ciphering information for LCS (see note) 


No 


Yes 


Measurement control information (idle period locations) 


Yes 


Yes 


Sectorisation of the neighbouring cells 


No 


Yes 


Measured RTD values for Cells mentioned at Intra 
frequency Cell Info 


No 


Yes 


RTD accuracy 


No 


Yes 


Measured roundtrip delay for primary serving cell 


No 


Yes 


Geographical location of the primary serving cell. 


No 


Yes 


Relative neighbour cell geographical location 


No 


Yes 


Accuracy range of the geographic location values 


No 


Yes 


NOTE: The idea behind LCS specific ciphering information is e.g. that the operator 
can sell information that the UE needs for calculating its location. For 
reference in the GSM world see [3]. 



The information required from UE to UTRAN (PSMF/PCF) is listed in table 9.2. 

Table 9.2: Information required for UE assisted and UE based OTDOA 
in the UE to UTRAN (PSMF/PCF) direction 



Information 


UE assisted 
OTDOA 


UE based 
OTDOA 


OTDOA measurement results 


Yes 


No 


OTDOA measurement accuracy 


Yes 


No 


UE geographical location 


No 


Yes 


Location accuracy indicator (based on the signalled and 
measurement accuracies) 


No 


Yes 



10 



Network assisted GPS location method 



When GPS is designed to inter-work with the UTRAJM, the network assists the UE GPS receiver to improve the 
performance in several respects. These performance improvements will: 

- reduce the UE GPS start-up and acquisition times; the search window can be limited and the measurements sped 
up significantly; 

increase the UE GPS sensitivity; location assistance messages are obtained via UTRAN so the UE GPS can 
operate also in low SNR situations when it is unable to demodulate UE GPS signals; 

allow the UE to consume less handset power than with stand-alone GPS ; this is due to rapid start-up times as the 
GPS can be in idle mode when it is not needed. 

The Network assisted GPS methods rely on signalling between possibly reduced complexity UE GPS receivers and a 
continuously operating GPS reference receiver network which has clear sky visibility of the same GPS constellation as 
the assisted UEs. GPS reference receivers may be connected to the UTRAN to enable derivation of UE assistance 
signals. 

NOTE 1: Labels in figure 10.1 may need to be ahgned with GSM 03.71. 

NOTE 2: Charging and billing operations are not illustrated in figure 10.1. 
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S-RNC 



Request to locate UE or 



request to issue assistance 
data to the UE 



UE 



S-RNC collects available network 
info about UE. 

S-RNC computesGPS 
assistance. 











Timing calibration. 

The timing 
calibration must be 
known at the RNC 
in order to provide 
timing assistance. 











GPS assistance information is conveyed 
to the UE 



UE makes GPS 
measurements with the help of 
GPS assistance information 



^GPS measur. results are conveyed to S- 



•RNC 



S-RNC calculates location 



UE location info 



^ (UE-assisted) 
NOTE: see reference [1]. 



UE calculates location fix 



UE location info 

(UE-based) 



Figure 10.1 : Network assisted GPS methods 



10.1 Timing calibration 

Timing calibration is specified in TS 25.215. 

10.2 Tinning assistance 

The UTRAN may derive the estimated UE location using UTRAN (eg. Cell-ID or IPDL) parameters and may use this 
information, in conjunction with satellite specific ephemeris data from the UTRAN based GPS reference receiver, to 
derive the estimated time difference (code phase) between equivalent GPS satellite signals received by the UTRAN 
based GPS reference receiver and the UE based GPS receiver. The estimated code phase data may be conveyed, 
together with Tutran-gps (as specified in TS 25.215), from the UTRAN to the UE using higher layer signalling. The 
estimated code phase data value is uncertain to a degree depending on the accuracy of the UTRAN location 
determination method used. 

10.3 Data assistance 

The UE may receive GPS information through the UTRAN air interface, using higher layer signalling. 

When the UE is unable to detect 4 or more satellites, the assisted GPS method can be combined with other location 
methods. 

The assistance data signalled to the UE may include all information listed below or a selected subset: 

data assisting the measurements; e.g. reference time, visible satellite list, satellite signal Doppler, code phase, 
Doppler and code phase search windows. This data is valid for a few minutes (e.g., less than 5 minutes); 

data providing means for location calculation; e.g. reference time, reference location, satellite ephemeris, clock 
corrections. This data is valid for four hours. 
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NOTE: Certain types of GPS Assistance data may be derived, wholly or partially, from other types of GPS 
Assistance data. 

If DGPS is utilised, then differential corrections may also be transmitted. They are valid for about 30 seconds. The 
DGPS data is valid for a large geographical area, so one centrally located reference receiver can be used to service this 
large region. 

10.4 UE search 

Both timing and data assistance shall be applied in the UE search procedure. 

"Modulation wipe-off" is defined here to mean a removal of the GPS spreading code modulation to GPS signals 
received at the UE, through the application of UTRAN timing and data assistance provided from the UTRAN to the UE. 

Modulation wipe off may be applied at the UE to derive the despread GPS data signal. 

10.5 Location determination 

Computation of the location fix can either be performed in the network infrastructure (UE-assisted) or in the UE 
(UE-based). 

There are two types of network assisted GPS method, namely UE-based and UE-assisted, which differ according to 
where the actual location calculation is carried out. 

10.5.1 UE-based method 

The UE-based method maintains a full GPS receiver functionality in the UE, and the location calculation is carried out 
by the UE, thus allowing stand-alone location fixes. 

If the location was requested by an application in the network, then the calculated location is signalled to the proper 
network element. 

The following information may be signalled from the UTRAN (LSIF) to the UE: 

number of satellites for which assistance is provided; 

reference time for GPS (Tutran-gps) (specified in TS 25.215); 

- reference location; 
ionospheric corrections; 

satellite ID for identifying the satellites for which the assistance is provided; 

ephemeris and clock corrections to accurately model the orbit of the particular satellite and information when 
this becomes valid; 

- UTC offset; 
DGPS corrections; 
almanac data. 

- real-time integrity (e.g., a list of unusable satellites). 

The following information may be signalled from the UE to the UTRAN (LSIF): 

reference time for GPS ; 

serving cell information; 

Latitude/Longitude/ Altitude/Error ellipse; 

velocity estimate of the UE; 

satellite ID for which the measurement data is valid; 

Whole/Fractional chips for information about the code-phase measurements; 
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C/Nq of the received signal from the particular satellite used in the measurements; 
doppler frequency measured by the UE fc)r the particular satellite signal; 
pseudorange RMS error; 
multipath indicator. 

10.5.2 UE-assisted method 

In the UE-assisted method, the UE employs a reduced complexity GPS receiver functionality. This carries out the 
pseudorange (code phase) measurements. These are signalled, using higher layer signalling, to the specific network 
element that estimates the location of the UE and carries out the remaining GPS operations. In this method, accurately 
timed code phase signalling (as specified in TS 25.215) is required on the downlink. The signalling load in the uplink 
direction can be larger than in the UE-based method. If DGPS is performed in the UE, then differential corrections must 
be signalled to it. On the other hand, DGPS corrections can be applied to the final result in the network to improve the 
location accuracy without extra signalling to the UE. 

The following information may be signalled from the UTRAN (LSIF) to the UE: 

number of satellites for which assistance is provided; 

- reference time for GPS (Tutran-gps) (specified in TS 25.215); 

satellite ID for identifying the satellites for which the assistance is provided; 
doppler (0* order term); 
doppler ( r' order term) ; 

- code phase; 

code phase centre and Search Window width; 

ephemeris; 

azimuth; 

elevation. 

The following information may be signalled from the UE to the UTRAN (LSIF): 

reference time for GPS (Tuegps) (specified in TS 25.215); 
number of Pseudoranges; 

- SVID; 

- satelUte C/No; 
doppler; 

satellite Code Phase; 
multipath Indicator; 

- pseudorange RMS Error. 

Additional parameters, such as round trip time (RTT), UE receiving transmitting time (UE RxTx), SFN-SFN observed 
time difference and CPICH Ec/No, may be used to improve the performance of UE-assisted GPS. All the additional 
parameters are defined in TS 25.215 and can be made available through RRC signalling. Furthermore, to those UE 
technologies requiring externally provided sensitivity and time aiding data, some navigation bits may be sent from 
UTRAN to UE for sensitivity assistance and time recovery. 



ETSI 



3G TS 25.305 version 3.2.0 Release 1 999 40 ETSI TS 1 25 305 V3.2.0 (2000-06) 

1 1 Other location methods 

11.1 Reference Node Based 

1 1 .2 Round Trip Time (RTT) 

This method makes use of measurements by the Node-B or LMU of the round trip time for transmissions to and from 
the UE. The RTT measurement message from Node-B or LMU to the UTRAN (PSMF/PCF) contains the following 
information: 

- round trip time (in fractional chips); 
time of measurement; 

- received sector; 

doppler of received signal (Hz); 
multipath Indicator. 

12 Position calculation functionality 

NOTE: The functionality of the PCF is described in more detail in an informative annex FES. 

13 Information storage 

NOTE This clause just outlines the information that may need to be stored in the UTRAN LCS elements (U- 
LCF, U-PSCF,U-LSCF, UE, etc) that may need to be standardised (if any). 



14 Operational aspects 
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Annex A (informative): 
Definitions and Terms 



This annex provides definitions and terms for the general LCS. Not all of these are applicable to the UTRAN 
environment. 

CAMEL: CAMEL is a network functionality, which provides the mechanisms of Intelligent Network to a mobile user. 

Current Location: after a location attempt has successfully delivered a location estimate and its associated time stamp, 
the location estimate and time stamp is referred to as the 'current location' at that point in time. 

Deferred location request: a location request where the location response (responses) is (are) not required 
immediately. 

Global Positioning System: the Global Positioning System (GPS) consists of three functional elements: Space 
Segment (satellites). User Segment (receivers), and Control Segment (maintenance etc.). The GPS receiver calculates 
its own location based on the received time differences for several satellites. 

Immediate location request: a location request where a single location response only is required immediately. 

Initial Location: in the context of an originating emergency call the location estimate and the associated time stamp at 
the commencement of the call set-up is referred to as 'initial location'. 

Last Known Location: the current location estimate and its associated time stamp for Target MS stored in the LCS 
Server is referred to as the 'last known location' and until replaced by a later location estimate and a new time stamp is 
referred to as the 'last known location'. 

LCS (Location Services): LCS is a service concept in system (e.g. GSM or UMTS) standardisation. LCS specifies all 
the necessary network elements and entities, their functionalities, interfaces, as well as communication messages, due to 
implement the location service functionality in a cellular network. 

NOTE: LCS does not specify any location based (value added) services except locating of emergency calls. 

LCS Client: a software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location 
information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information. 
LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting 
data and managing the user interface (dialogue). The LCS Client may reside in the Mobile Station (MS). 

LCS Client Access barring list: an optional hst of MSISDNs per LCS Client where the LCS Client is not allowed to 
locate any MSISDN therein. 

LCS Client Subscription Profile: a collection of subscription attributes of LCS related parameters that have been 
agreed for a contractual period of time between the LCS client and the service provider. 

LCS Feature: the capability of a PLMN to support LCS Client/server interactions for locating Target MSs. 

LCS Server: a software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services 
requests, and sends back responses to the received requests. The LCS server consists of LCS components, which are 
distributed to one or more PLMN and/or service provider. 

Local Service: a service, which can be exclusively provided in the current serving network by a Value added Service 
Provider. 

Local Information: information related to a given location, or general information, which is made available in a given 
location. 

Location (/location detecting): location is a functionality, which estimates a geographical location (of e.g. a mobile 
terminal). 

Location (Based) Application: a location application is an application software processing location information or 
utilising it in some way. The location information can be input by a user or detected by network or MS. Navigation is 
one location application example. 
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Location Based Service (LBS): a service provided either by teleoperator or a 3' party service provider that utilises the 
available location information of the terminal. Location Application offers the User Interface for the service. LBS is 
either a pull or a push type of service (see Location Dependent Services and Location Independent Services). In 
ETSI/GSM documentation of SoLSA, LBS is called "Location Related Service". ETSI and/or 3GPP -wide terminology 
harmonisation is expected here. 

Location Dependent Service: a service provided either by teleoperator or a 3"* party service provider that is available 
(pull type) or is activated (push type) when the user arrives to a certain area. It doesn't require any subscription in 
advance, but the push type activation shall be confirmed by the user. The offered service itself can be any kind of 
service (e.g. a public Xerox machine or the discount list in a store). 

Location Estimate: the geographic location of an MS and/or a valid Mobile Equipment (ME), expressed in latitude and 
longitude data. The Location Estimate shall be represented in a well-defmed universal format. Translation from this 
universal format to another geographic location system may be supported, although the details are considered outside 
the scope of the primitive services. 

Location Independent Service: a service provided either by teleoperator or a 3"* party service provider that is available 
and therefore can be activated anywhere in the network coverage. It is activated by the user's request or by other user's 
activated service, and therefore it requires a subscription in advance (pull type). The offered service itself can be any 
kind of service (e.g. MMS, S WDL, or LBS !). 

Location method (/locating method): a principle and/or algorithm which the estimation of geographical location is 
based on, e.g. AOA, TOA, TDOA. For example, GPS is based on TOA, and E-OTD (on GSM) is based on TDOA. 

Location technology (/locating technology): a technology or system concept including the specifications of RF 
interfaces, data types, etc. to process the estimation of a geographical location, e.g. GPS, E-OTD (GSM), and IPDL- 
TDOA (WCDMA). 

PLMN Access barring list: an optional list of MSISDN per PLMN where any LCS Client is not allowed to locate any 
MSISDN therein except for certain exceptional cases. 

Predefined area: a geographical area which is not related to cell or radio coverage. The mobile may take special action 
when it recognises it has entered or left a predefined area. 

Privacy Class: list of LCS Clients defined within a privacy exception class to which permission may be granted to 
locate the target MS. The permission shall be granted either on activation by the target MS or permanently for a 
contractual period of time agreed between the target MS and the service provider. 

Privacy Exception List: a list consisting of various types of privacy classes (i.e. operator related, personal etc.). 
Certain types of classes may require agreement between the service provider and the target MS. 

Prohibited area: an area where the mobile must not activate its transmitter. The Prohibited area may be a Predefined 
area described above or related to radio cell(s). 

Subscription Profile: the profile detailing the subscription to various types of privacy classes. 

Target MS: the MS being located. 
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